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Executive  Bulletin 


Problems  Occur  When 
You  Can  Least  Afford 
Them,  So  Planning 
|s  Critical 

With  tornadoes  in  the  Midwest,  April 
snows  in  Colorado,  a  6.2  (Richter  scale) 
earthquake  in  San  Jose  near  the  heart  of 
Silicon  Valley,  and  heavy  rains  in  the 
Northeast  and  Southeast,  it  should  be 
obvious  to  one  and  all  that  nature  causes 
disasters  from  which  you,  the  information 
system  manager,  must  recover. 

The  subject  of  disaster  recovery  plan- 
ning, much  like  insurance,  is  one  that  most 
of  us  prefer  to  ignore.  This  is  not  because 
we  don't  recognize  the  importance  of 
creating  and  honoring  such  a  plan,  but 
because  we  always  have  other,  more  time- 
critical  commitments. 

This  Executive  Bulletin  will  outline  key 
basic  items  that  you  should  deal  with  now, 
in  advance  of  a  disaster.  Such  items 
include: 

1.  Storage. 

2.  Key  personnel. 

3.  Processing  facilities. 
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We  at  INPUT  strongly  suggest  that  you 
take  the  time  to  at  least  do  some  basic, 
preliminary  preparation  for  the  "it  could 
never  happen  to  us"  disaster,  whether  it  is 
natural  or  otherwise.  Specifically  we 
suggest  that  you: 

1 .  Create  (and  keep  current)  a  method  for 
storing  files,  programs,  documentation, 
etc. 

2.  Create  (and  keep  current)  a  list  of  key 
personnel  required  to  keep  your 
company's  systems  running. 

3.  Have  available  (and  not  only  in  your 
desk)  as  comprehensive  a  list  as  pos- 
sible of  local,  or  near-local,  processing 
facilities,  plus  the  arrangements  you 
(hopefully)  have  already  made  with 
these  facilities.  ,^  n 

File,  Data,  and  Proqn 

As  the  one  responsible  for  information 
system  management,  your  focus  should  be 
on  the  key  word~information~without 
which  there  is  no  business.  Finding  an  off- 
site  vault  location  (at  which  you  can  store 
all  of  your  master  files,  program  listings, 
processing  documentation,  et  al)  is  an  easy 


proposition.  (This  is  different  from  hiring 
an  off-site  Disaster  Recovery  Service, 
although  if  you  hire  one  the  problem  of  off- 
site  storage  of  critical  information  and  the 
problem  of  overall  recovery  can  be  handled 
at  one  time.)  The  exact  distance  this 
location  should  be  from  your  operating 
center  is  dependent  upon  the  type  of  major 
disaster  most  likely  to  occur.  If,  for 
example,  flooding  is  a  possibility  then  logic 
dictates  that  your  off-site  vault  be  main- 
tained in  a  location  that  is  not  going  to  be 
affected  by  the  same  natural  catastrophe. 

Once  you  have  selected  the  site,  you 
need  to  copy  and  catalog  all  of  the  informa- 
tion that  should  be  maintained  at  this 
location.  Additional  copies  of  this  catalog 
should  be  kept  off-site,  preferably  at  a 
branch  location  and  at  some  of  the  homes 
of  the  key  personnel.  This  catalog,  and  the 
data  that  is  stored  off-site,  has  to  contain 
all  of  your  "must"  systems  and  as  many  of 
your  "also  important"  systems  as  you  can 
reasonably  keep  current  given  the  ongoing 
requirements  of  your  operation. 

This  leads  us  to  the  final  point  of  this 
section—making  sure  that,  as  you  back  up 
your  system  for  normal  security  purposes, 
you  transfer  updated  master  files,  neces- 
sary transaction  files  and,  if  pertinent,  new 
documentation  files  (or  hard  copy)  to  the 
off-site  vault.  This  ongoing  effort  must  be 
done  at  least  monthly  and  should  probably 
be  done  on  a  weekly  basis  to  preclude 
having  to  manually  recreate  as  much  as  30 
days  worth  of  transaction  data.  If  a  dis- 
aster  does   occur  you'll   have   lots  more 


important  things  to  worry  about  than  catch- 
ing up  with  already-completed  work. 


Key  Personnel 

If  a  disaster  occurs,  the  key  word  to 
remember  is  disaster.  You  will  potentially 
have  to  process  information  in  a  scramble 
mode.  In  a  worst  case  situation,  you  not 
only  can  lose  your  system  but  some  of  your 
key  people  as  well.  (This  is  a  gruesome 
thought,  but  the  contingency  must  be 
prepared  for.)  Other  staff  members  will 
have  to  process  as  much  information  as 
they  can  with  limited  supervision  and 
decreased  processing  capabilities. 

By  maintaining  in  at  least  three  loca- 
tions (the  vault,  on-site,  and  at  the  house  of 
one  or  more  staff  members)  a  list  of  all  key 
personnel,  you  will  still  have  an  ability  to 
process.  For  each  person  identified,  there 
should  be  at  least  one,  preferably  two, 
backup  individuals  who  can  support  your 
processing  needs.  Operations,  applications 
programming,  and  systems  software  are  the 
three  disciplines  that  must  be  protected. 
Customer  support,  documentation,  data 
entry,  etc.  are  also  important  but  usually  to 
a  lesser  degree  than  these  first  three. 

As  a  part  of  this  program  you  need  to 
ensure  that  all  personnel  that  will  be  called 
upon  in  a  disaster  are  trained  in  the  proce- 
dures they  will  follow.  Dry  runs,  including 
actually  shutting  down  your  system,  should 
I  be  implemented. 


If  you  are  a  one-shift,  one-level-of-  | 
staffing  shop,  you  need  to  consider  locating 
and  arranging  for  a  third  party  to  support 
your  system  when  the  need  arises,  in  this 
case,  the  l<ey  contact  information  regarding 
this  outside  organization  should  also  be  kept 
at  the  locations  mentioned  above. 


Processing  Focilities 

You  now  have  the  people,  the  pro- 
grams, reasonably  current  updated  records, 
and  documentation.  All  you  need  now  is  a  | 
computer  and  a  place  to  run  it.  Remember- 
ing still  that  disaster  is  the  key  word,  you 
will  have:  I 

a)  Arranged  with  a  sister  firm  in  another 
locale  to  support  your  needs  for  some 
period  of  time.  (Remember  that  these 
kinds  of  arrangements  are  usually 
reciprocal.) 

b)  Arranged  with  a  service  organization  in 
another  location  to  support  you  until 
your  installation  has  recovered. 

c)  Arranged  for  a  space-only  location  into 
which  a  new  hardware  configuration 
can  be  delivered  as  soon  as  your  vendor 
can  supply  you  with  the  needed  equip- 
ment. 

In  addition,  you,  as  part  of  this  re- 
quirement, will  have  a  guarantee  from  your 
vendor  describing  how  long  it  will  take  to 


get  that  new  system  to  your  space-only 
backup  site  or  to  your  new  or  renovated 
location. 

By  covering  these  three  areas,  you  give 
yourself  primary  protection  against  a 
disaster  putting  your  organization  in  an 
operating  bind  or,  at  the  very  worst,  out  of 
business.  There  are  a  lot  of  other  items 
that  need  to  be  looked  at  in  order  to  pro- 
perly complete  a  disaster  recovery  plan, 
including  arrangements  for  transportation, 
data  entry,  communications,  supplies,  etc. 
But,  by  handling  the  basic  three  indicated 
above,  you  should  be  able  to  keep  yourself 
going  regardless  of  the  magnitude  of  the 
disaster. 

And,  almost  as  a  by-product,  you  have 
begun  a  formal  disaster  recovery  plan  that 
you  should  try  to  complete  as  soon  as  you 
can  find  the  time  or  get  out  from  under 
other  priorities. 

It  is  in  your  best  interest  overall  to 
prepare  and  fully  document  a  detailed 
disaster  recovery  program  that  at  least 
covers  the  following  items: 

Initial  notification  procedures. 
Plan  organization  and  structure. 
Plan  activation  criteria. 
Off-site  storage  procedures. 
Vault  resource  requirements  listing. 
Software  restoration  procedures. 
Off-site  checklists. 
1/0  responsibilities. 

Critical  run  reconstruction. 

Schedules. 


Administrative  procedures. 

Personnel. 

Security. 

Transportation. 

insurance. 
.  PR. 

Legal. 

Purchasing/supply. 
-    User  support  requirements. 
Application  specialists. 
User  data  reconstruction. 
Critical       Data  Application 
Schedules. 
Special  call  list. 
Communications  links. 
Testing  procedures. 
Audits. 
Reviews. 

When  these,  plus  others,  are  completed  you 
will  have  a  full  plan—documented,  tested, 
I  and  proven. 

Whether  you  choose  to  hire  an  outside 
service,  rent  a  shell,  or  rent  a  full  backup 
facility,  you  still  need  the  plan  and  you 


need  to  convince  senior  management  that 
the  failure  to  have  such  a  plan  can  poten- 
tially put  you  out  of  business.  The  avail- 
ability of  a  plan  can  expedite  recovery  from 
a  disaster  as  simple  as  a  flood  in  the 
computer  room  or  as  complex  as  complete 
destruction  of  the  machine  facility  and 
everything  (and  everybody)  inside. 

This  Executive  Bulletin  reminds  you 
that  not  only  does  it  not  pay  to  fool  with 
Mother  Nature,  but  also  it  doesn't  pay  to 
ignore  her. 


This  INPUT  Executive  Bulletin  is 
published  as  part  of  the  Corporate  Systems 
Planning  Program  of  the  Information 
Systems  Program.  For  more  information  on 
this  bulletin  or  any  other  INPUT  program, 
please  contact  INPUT  at  1943  Landings 
Drive,  Mountain  View,  California  94043, 
(415)  960-3990. 
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A  REMINDER  THAT  PROBLEMS  OCCUR 
WHEN  YOU  CAN  LEAST  AFFORD  THEM 
BUT  WITH  TIMELY  PLANNING  YOU  CAN 
REDUCE  THEIR  IMPACT 

With  tornadoes  in  the  Midwest,  April 
snows  in  Colorado,  a  6.2  (Richter  scale) 
earthquake  in  San  Jose  near  the  heart  of 
Silicon  Valley,  and  heavy  rains  in  the 
Northeast  and  Southeast,  it  should  be 
obvious  to  one  and  all  that  nature  causes 
disasters  from  which  you,  the  information 
system  manager,  must  recover. 

The  subject  of  disaster  recovery 
planning,  much  like  insurance,  is  one  that 
most  of  us  prefer  to  ignore.  This  is  not 
because  we  don't  recognize  the  importance 
of  creating  and  honoring  such  a  plan,  but 
because  we  always  have  other,  more  time- 
critical  commitments. 

This  Executive  Bulletin  will  outline  key 
basic  items  that  you  should  deal  with  now, 
in  advance  of  a  disaster.  Such  items 
include: 

1.  Storage. 

2.  Key  personnel. 

3.  Processing  facilities. 

We  at  INPUT  strongly  suggest  that  you 
take  the  time  to  at  least  do  some  basic, 
preliminary  preparation  for  the  "it  could 
never  happen  to  us"  disaster,  whether  it  is 


natural  or  otherwise.  Specifically  we 
suggest  that  you: 


1 .  Create  (and  keep  current)  a  method  for 
storing  files,  programs,  documentation, 
etc. 

2.  Create  (and  keep  current)  a  list  of  key 
personnel  required  to  keep  your 
company's  systems  running. 

3.  Have  available  (and  not  only  in  your 
desk)  as  comprehensive  a  list  as 
possible  of  local,  or  near-local, 
processing  facilities,  plus  the 
arrangements  you  (hopefully)  have 
already  made  with  these  facilities. 

File,  Data,  and  Program  Storage 

As  the  one  responsible  for  information 

system  management,  your  focus  should  be 

on  the  key  word.-  information.-  without 
^  A 

which  there  is  no  business.  Finding  an  off- 
site  vault  location  (at  which  you  can  store 
all  of  your  master  files,  program  listings, 
processing  documentation,  et  al)  is  an  easy 
proposition.  (This  is  different  from  hiring 
an  off -site  Disaster  Recovery  Service, 
although  if  you  hire  one  the  problem  of  off- 
site  storage  of  critical  information  and  the 
problem  of  overall  recovery  can  be  handled 
at  one  time.)  The  exact  distance  this 
location  should  be  from  your  operating 
center  is  dependent  upon  the  type  of  major 


I 


disaster  most  likely  to  occur.  If,  for 
example,  flooding  is  a  possibility  then  logic 
dictates  that  your  off-site  vault  be 
maintained  in  a  location  that  is  not  going  to 
be  affected  by  the  same  natural 
catastrophe. 

Once  you  have  selected  the  site,  you 
need  to  copy  and  catalog  all  of  the 
information  that  should  be  maintained  at 
this  location.  Additional  copies  of  this 
catalog  should  be  kept  off-site,  preferably 
at  a  branch  location  and  at  some  of  the 
homes  of  the  key  personnel.  This  catalog, 
and  the  data  that  is  stored  off-site,  has  to 
contain  all  of  your  "must"  systems  and  as 
many  of  your  "also  important"  systems  as 
you  can  reasonably  keep  current  given  the 
ongoing  requirements  of  your  operation. 

This  leads  us  to  the  final  point  of  this 
sections-making  sure  that,  as  you  back  up 
your  system  for  normal  security  purposes, 
you  transfer  updated  master  files, 
necessary  transaction  files  and,  if 
pertinent,  new  documentation  files  (or  hard 
copy)  to  the  off-site  vault.  This  ongoing 
effort  must  be  done  at  least  monthly  and 
should  probably  be  done  on  a  weekly  basis 
to  preclude  having  to  manually  recreate  as 
much  as  30  days  worth  of  transaction 
data.  If  a  disaster  does  occur  you'll  have 
lots  more  important  things  to  worry  about 
than  catching  up  with  already-completed 
work. 
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Key  Personnel 


If  a  disaster  occurs,  the  key  word  to 
remember  is  disaster.  You  will  potentially 
have  to  process  information  in  a  scramble 
mode.  In  a  worst  case  situation,  you  not 
only  can  lose  your  system  but  some  of  your 
key  people  as  well.  (This  is  a  gruesome 
thought,  but  the  contingency  must  be 
prepared  for.)  Other  staff  members  will 
have  to  process  as  much  information  as 
they  can  with  limited  supervision  and 
decreased  processing  capabilities. 

By  maintaining  in  at  least  three 
locations  (the  vault,  on-site,  and  at  the 
house  of  one  or  more  staff  members)  a  list 
of  all  key  personnel,  you  will  still  have  an 
ability  to  process.  For  each  person 
identified,  there  should  be  at  least  one, 
preferably  two,  backup  individuals  who  can 
support  your  processing  needs.  Operations, 
applications  programming,  and  systems 
software  are  the  three  disciplines  that  must 
be  protected.  Customer  support, 
documentation,  data  entry,  etc.  are  also 
important  but  usually  to  a  lesser  degree 
than  these  first  three. 

As  a  part  of  this  program  you  need  to 
ensure  that  all  personnel  that  will  be  called 
upon  in  a  disaster  are  trained  in  the 
procedures  they  will  follow.  Dry  runs, 
including  actually  shutting  down  your 
system,  should  be  implemented. 
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If  you  are  a  one-shift,  one-level-of- 
staffing  shop,  you  need  to  consider  locating 
and  arranging  for  a  third  party  to  support 
your  system  when  the  need  arises.  In  this 
case,  the  key  contact  information  regarding 
this  outside  organization  should  also  be  kept 
at  the  locations  mentioned  above. 

Processing  Facilities 

You  now  have  the  people,  the 
programs,  reasonably  current  updated 
records,  and  documentation.  All  you  need 
now  is  a  computer  and  a  place  to  run  it. 
Remembering  still  that  disaster  is  the  key 
word,  you  will  have: 

a)  Arranged  with  a  sister  firm  in  another 
locale  to  support  your  needs  for  some 
period  of  time.  (Remember  that  these 
kinds  of  arrangements  are  usually 
reciprocal.) 

b)  Arranged  with  a  service  organization  in 
another  location  to  support  you  until 
your  installation  has  recovered. 

c)  Arranged  for  a  space-only  location  into 
which  a  new  hardware  configuration 
can  be  delivered  as  soon  as  your  vendor 
can  supply  you  with  the  needed 
equipment. 

In  addition,  you,  as  part  of  this 
requirement,  will  have  a  guarantee  from 


your  vendor  describing  how  long  it  will  take 
to  get  that  new  systenn  to  your  space-only 
backup  site  or  to  your  new  or  renovated 
location. 

By  covering  these  three  areas,  you  give 
yourself  primary  protection  against  a 
disaster  putting  your  organization  in  an 
operating  bind  or,  at  the  very  worst,  out  of 
business.  There  are  a  lot  of  other  items 
that  need  to  be  looked  at  in  order  to 
properly  complete  a  disaster  recovery  plan, 
including  arrangements  for  transportation, 
data  entry,  communications,  supplies,  etc. 
But,  by  handling  the  basic  three  indicated 
above,  you  should  be  able  to  keep  yourself 
going  regardless  of  the  magnitude  of  the 
disaster. 

And,  almost  as  a  by-product,  you  have 
begun  a  formal  disaster  recovery  plan  that 
you  should  try  to  complete  as  soon  as  you 
can  find  the  time  or  get  out  from  under 
other  priorities. 

It  is  in  your  best  interest  overall  to 
prepare  and  fully  document  a  detailed 
disaster  recovery  program  that  at  least 
covers  the  following  items: 

Initial  notification  procedures. 

-  Plan  organization  and  structure. 

-  Plan  activation  criteria. 
Off-site  storage  procedures. 

-  Vault  resource  requirements  listing. 

-  Software  restoration  procedures. 

-  Off-site  checklists. 
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-  I/O  responsibilities. 

Critical  run  reconstruction. 
Schedules. 

-  Administrative  procedures. 

Personnel. 
Security. 
Transportation. 
Insurance. 
.  PR. 
Legal. 

Purchasing/supply. 

-  User  support  requirements. 

Application  specialists. 

User  data  reconstruction. 
.    Critical  Data  Application 

Schedules. 
.    Special  call  list. 

Communications  links. 

-  Testing  procedures. 

Audits. 
Reviews. 

When  these,  plus  others,  are  completed  you 
will  have  a  full  plan— documented,  tested, 
and  proven. 

Whether  you  choose  to  hire  an  outside 
service,  rent  a  shell,  or  rent  a  full  backup 
facility,  you  still  need  the  plan  and  you 
need  to  convince  senior  management  that 
the  failure  to  have  such  a  plan  can 
potentially  put  you  out  of  business.  The 
availability  of  a  plan  can  expedite  recovery 
from  a  disaster  as  simple  as  a  flood  in  the 
computer  room  or  as  complex  as  complete 
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destruction  of  the  machine  facility  and 
everything  (and  everybody)  inside. 

This  Executive  Bulletin  reminds  you 
that  not  only  does  it  not  pay  to  fool  with 
Mother  Nature,  but  also  it  doesn't  pay  to 
ignore  her. 

This  INPUT  Executive  Bulletin  is 
published  as  part  of  the  Corporat-^fv^ 
Systems  Planning  Program  of  the 
Information  Systems  Program.  For  more 
information  on  this  bulletin  or  any  other 
INPUT  program,  please  contact  INPUT  at 
1943  Landings  Drive,  Mountain  View, 
California  94043,(415)  960-3990. 
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A  REMINDER  THAT  PROBLEMS  OCCUR 
WHEN  YOU  CAN  LEAST  AFFORD  THEM 
BUT  WITH  TIMELY  PLANNING  YOU  CAN 
REDUCE  THEIR  IMPACT 


With  tornadoes  in  the  Midwest,  April 
snows  in  Colorado,  a  6.2  ofi-4^^ichter 
scole^ 

earthquake  heart  of 

Silicon  Valley,  heavy  rains  in  the  Northeast 
and  Southeast,  it  should  be  obvious  to  one 
and  all  that  nature  causes  disasters  from 
which  you,  the  information  system 
manager,  must  recover. 

Mtjch4tke'lhe  wdLomc  given  to  an 
siirance  .sfltespersefi,  which  is  at  best  ■ 


0 


> 


i'eluctaiYt>!\tiie  subject  of  disaster  recovery 

»>»iycK  (lite  ifisymnta, 
planning  is  one  that  most  of  us  prefer  to 
/>/ 

\,      ignore^  Not  because  we  don't  recognijf^  the 


importance  of  creating  and  honoring  such  a 

plan^but  because  we  always  have  other/^  m^T*^ 

^— moP€  prGS8in§/tim^critical  commitments^  ^ 

thet-fill  our  timfv-^  «^  ^ 

We  at  INPUT/^trongly  suggest/that 

you  take  the  time  to  at  least  do  some  basic, 

preliminary  preparation  for  +n«tt  "oeveF- 

dkW^K,  <»  9- 

happen  to  us"  event,  whether  it  is  naturally-^ 
or  otherwis^cQuscdj^^ Specifically  we 
suggest  that  you: 


I .  Create  (and  keep  current)  a  method  for 
storing  files,  programs,  documentation, 
etc. 
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2.  Create  (and  keep  current)  a  list  of  key 
personnel  required  to  keep  your 
company's  systems  runrjing. 

3.  Have^^Hoble^^^^ot  only  in  your 
desk)  Qs^comprehensive 

possible  of  local,  or  near-local,  1 

processing  facilitie^lus  the  n     ^.^yo^  do  (2, 

arrangements  you  (hopefully)  have.,  (]   /  Vs)^  „ 

already  put  in  plac>e  with  theww-  ^  J^J^  v 

File,  Data,  ond  Program  Storage  ' 

As  the  one  responsible  for  Information 
system  managemen^your  focus  should  be  on 
the  key  word  -  information  -  without  which 
there  is  no  business.  Finding  an  off-site 
vault  location^t  which  you  can  store  all  of 
your  master  files,  program  listings, 
processing  documentation,  et  ajj^is  an  easy 
proposition.  (This  is  different  from  hiring 
an  off-site  Disaster  Recovery  Service/s,  ^ 
although  if  you  do  this,  the  problem  of  off-  '  n 

 '  /Vl  ^vM^  ^ 

site  storage  of  criticoMnffirmation  and  the  .  J 

problem  of  >^-ecover^  overall  jean  be  handled  yyyU/t^'*^''^^^^ 
at  one  time.)  The  exact  distance  this  ^         ^  7 

location  should  be  from  your  operating 
center  is  dependent  upon  the  type  of  major 
disaster  most  likely  to  occur.  If,  for 
example,  flooding  is  a  possibility  then  logic 
dictates  that  your  off-site  vault  be 
maintained  in  a  location  that  is  not  going  to 
be  affected  by  the  same  natural 
catastrophe. 
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Once  you  have  selected  the  site,  you 
need  to  copy  and  catalog  all  of  the 
Information  that  should  be  maintained  at 
this  location.  Additional  copies  of  this 
catalog  should  be  kept  off-site,  preferably 

A 

at  a  branch  location  and  at  some  of  the 

■Mr- 

homes  of  the  key  personneL'/uu  Will  CilW 


dioaotcr  uului  i.  This  catalog,  and  the  data 
that  is  stored  off-site,  has  to  contain  all  of 
your  "must"  systems  and  as  many  of  your 
"also  important"  systems  as  you  can 
reasonably  keep  current  given  the  ongoing 
requirements  of  your  operation. 


section  -  making  sure  that,  as  you  back  up 
your  system  for  normal  security  purposes, 
you  transfer  updated  master  files, 
necessary  transaction  files  and,  if 
pertinent,  new  documentation  files  (or  hard 
copy)  to  the  off-site  vault.  This  ori^oing 
effort  must  be  done  at  least  monthly  and 
should  probably  be  done  on  a  weekly  basis  i^ 
ordor^to  preclude  a-need  t^have  to    Ka.*/'*^  1^ 
manually  recreate  as  much  as  30  days  worth 
of  transaction  data.  If  a  disaster  does 
occur  you'll  have  lots  more  important  things 
to  worry  about  than  catching  up  with 
already-completed  work. 
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Key  Personnel 


disaster  occurs,  the  key 
word  to  remember  is  disaster.  You  will 
potentially  have  to  process  information  in  a 
scramble  mode.  In  a  worst  case  situation, 
you  not  only  can  lose  your  system  but  yotr^^ 
^corHese  some  of  your  key  people  as  well. 

(t  ^ri  iAQoiT^A-Ti^i'^«jgt'^%»^  it  >    ■)j  ^'TKt'-^w^apg  O 

^  tha-t  other  staff  members  will  have  to  tf-y-te-^ 
process  as  much  ©t4h^nformation^they 
can  with  limited  supervision  and  decreased 
processing  capabilities. 

ByunaintQ^ning  a  li^st  of  ^11  key 
per  son  ne^i<^^tJeastJlT^^ 

vault,  orvWt^To^'^'alTTT^^ 
more)  staf^  memb(^rs'^ou\^if^n( 
ability  to  process.  For  each  person 
identified,  there  should  be  at  least  one, 
preferably  two,  back'^p  individuals 
ifidte«te^who  can  support  your  processing 
needs.  Operations,  applications 
programminc^and  systems  software  are  the 
three  disciplines  that  must  be  protected  « 
ja^itlft;ustomer  support,  documentation,  data 
entry,  etc.  important  but  usually  to  a  lesser 
degree  than  these  first  three. 


Si  mink/yjH  'i^^  ^^^^  -u 

.        ^  ^ 


-  4  -  (MMEB-2)  TE  6/30/84 


I 


As  a  part  of  this  progrpm^ou  need  to 
ensure  that  all  personnel  th^jffj^be  called 
upon  in  a  disaster  ^^rained  in  the 
procedures  they  will  follow.  Dry  runs, 
including  actually  shutting  down  your 

system,  should  be  innplemented  i(and  not^  

QOiyjduring  a  tinno  poriod-when  the^^ 
■■M'TTmHi^^  not  addresgfid^ng* 

If  you  are  a  one-shift,  one-level-of- 
staffing  shop,  you  need  to  consider  locating 
and  arranging  for  a  third  party  to  support 
your  system  when  the  need  arises.  In  this 
case,  the  key  contact  infornriation  regarding 
this  outside  organization  ts^kept  at  the 
locations  mentioned  above. 

Processing  Facilities 

You  now  have  the  people,  the 
programs,  reasonably  current  updated 
records^nd  documentation.  All  you  need 
now  is  a  computer  and  a  place  to  run  it. 
Remembering  still  that  disaster  is  the  key 
word,  you  will  have: 

a)  Arranged  with  a  sister  firm  in  another 
locale  to  support  your  needs  for  some 
period  of  time.  (Remember  that  these 
kinds  of  arrangements  are^redprX;al.) 

A 

b)  Arranged  with  a  service  organization  in 
another  location  to  support  you  until 
your  installation  has  recovered. 
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c)    Arranged  for  ap  space^nly  location 
into  which  a  new  hardware 
configuration  can  be  delivered  as  soon 
as  your  vendor  can  supply  you  with  the 
needed  equipment. 

In  addition,  you,  as  part  of  this 

requirement,  will  have  a  guarantee  from 

your  vendor  describing  how  long  it  will  take 

to  get  that  new  system  to  your  space-only 

A 

backup  site  or  to  your  new  or  renovated 
location. 

By  covering  these  three  areas,  you  give 
yourself  primary  protection  against  a 
disaster  putting  your  organization  in  an 
operating  binc|(|or/at  the  very  worst,  out  of 
business.  There  are  a  lot  of  other  items  ,  , 

that  need  to  be  looked  at  in  Tho^ropcr  ' 
.y^^cofwpfetiofvdf  a  disaster  recovery  plan/\ 
including  arrangements  foiV^ transportation, 
data  entry,  communications,  supplies,  etc. 
But,  by  handling  the  basic  three  indicated 
above,  you  should  be  able  to  keep  yourself 
going  regardless  of  the  magnitude  of  the 
disaster. 

And,  almost  as  a  b>4jproduct^ou  have 
begun  a  formal  disaster  recovery  plan  that 
you  should  try  to  complete  as  soon  as  you 
can  find  the  time  or  get  out  from  under 
•ttT&s^other  priorities. 

It  is  in  your  best  interest  overall  to 
prepare  and  fully  document  a  detailed 
disaster  recovery  program  that  at  least 
covers  the  following  items: 
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Initial  notification  procedures. 
Plan  organization  and  structure. 
Plan  activation  criteria. 
Off-site  storage  procedures. 
Vault  resource  requirements  listing. 
Software  restoration  procedures. 
Off-site  checklists. 
I/O  responsibilities. 

Critical  run  reconstruction. 
Schedules. 
Administrative  procedures. 
Personnel. 
Security. 
Transportation. 
Insurance. 
PR. 
Legal. 

Purchasing/supply. 
User  support  requirements. 
Application  specialists. 
User  data  reconstruction. 
Critical  Data  Application 
Schedules. 
Special  call  list. 

Communications  links. 
Testing  procedures. 
Audits. 
Reviews. 

When  these,  plus  others,  are  completed  you 
will  have  a  full  plar^^ocumented,  tested, 
and  proven. 
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Whether  you  choose  to  hire  an  outside 
service,  rent  o  shell,  or  rent  a  full  backup 
facility,  you  still  need  the  plan  and  you 
need  to  convince  senior  management  that 
the  failure  to  have  such  a  plan  can 
potentially  put  you  out  of  business.  The 
availability  of  a  plan  can  expedite  recovery 
from  a  disaster  as  simple  as  a  flood  in  the 

0/ 

computer  room  ts^as  complex  as  complete 


^Kitrtijui^Iorf^of  the 


chine  facility  and 


everything  (ana-p4F«oo)  inside. 

This  Ek^cutive  Bulletin  io  jntendod  t^ 

rerrrms  you  that  not  only  dpesr#  it  Ref  pay 

to  fool  with  mother  nature,  it  doesn't  pay  to 

)      A  i  , 

ignore  her  either.  ' 

Th^  INPUT  Executive  Bulletin  is 

published  as  part  of  the  Corporation 

Systems  Planning  Program  of  the 

Information  Systems  Program.  For  more 

information  on  this  bulletin  or  any  other 

INPUT  program,  please  contact  INPUT  at 

1943  Landings  Drive,  Mountain  View, 

California  94043,(415)  960-3990. 


7^  ^yecuH^t  Bullei-i^  re^i^ 
p^y  ^  foci  Vf^/, 
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A  REMINDER  THAT  PROBLEMS  OCCUR 
WHEN  YOU  CAN  LEAST  AFFORD  THEM 
BUT  WITH  TIMELY  PLANNING  YOU  CAN 
REDUCE  THEIR  IMPACT 

With  tornadoes  in  the  Midwest,  April 
snows  in  Colorado,  a  6.2  on  the^ichtej|4cale 
earthquake  in  San  Jose  near  the  heart  of 
Silicon  Valley,  heavy  rains  in  the  Northeast 
and  Southeast,  it  should  be  obvious  to  one 
and  all  that  nature  causes  disasters  from 
which  you,  the  information  system 
manager,  must  recover.  ^'"^^^S 


Much  like  the«we!corne  ^^^_\to  an      *      _  -r- 
insurance  salesperson^ fhe  subject  of 
disaster  recovery  planning  is  one  that  most 
of  us  prefer  to  ignore.  Not  because  we 
don't  recognise  the  importance  of  honoring 
such  a  plan  but  because  we  always  have 
other  more  pressing,  time-critical 
commitments  that  fill  our  time. 

B£  that  as  it  moy^^  at  INPUT, 

strongly  suggest,  that  you  take  the  time  to 

at  least  do  some  basic,  preliminary 
/' 

preparation  for  that  never  happen  to  us  - 
eventj  Specifically  we  suggest  that  you: 

1 .  Create  (and  keep  current)  a  method  for 
storing  files,  programs,  documentation, 
etc. 

2.  Create  (and  keep  current)  a  list  of  key 
personnel  required  to  keep  your 
company's  systems  running. 
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Have  available  (not  in  your  desk)  as 
A 

comprehensive  a  list  as  possible  of 


local,  or  near  local,  processing  . 

facilitiesf^*  -fke  CHHt^<-., — 1*^13         C)-o,mls^uJjDv^  Ufi^oJ^JutJ^  ^loCT ^  pl^ 


File,  Data,  orxi  Program  Storage 


As  the  one  responsible  for  infornnation 
system  management  your  focus  should  be  on 
the  key  woijfc  -  information  -  without  which 
there  is  no  business.  Finding  an  offj^site 
vault  location  at  which  you  can  store  all  of 
your  master  files,  program  listings, 
processing  documentation,  et  ol  is  an 
proposition.''The  e^<act~distance  this" 
location  should  be  from  your  operating 
center  is  dependent  upon  the  type  of  major 
disaster  most  likely  to  occur.  If,  for 
example,  flooding  is  a  possibility  then  logic 
dictates  that  your  off-site  vault  be 
maintained  in  a  location  that  is  not  going  to 
be  affected  by  the  same  natural 
catastrophe. 

Once  you  have  selected  the  site,  yoi^ 
need  to  copy  and  catalog  all  of  the 
information  that  sbpuLd  be  maintained  at 
this  location.  ^Copies  of  th^  catalog^sl^oyijd^-^— ^  et'^cCr 
be  kept  off  site  preferably  at  some  of  the 
hornes  of  the  key  personnel  you  will  call 
upon  to  proces^when      a  disaster  occurs. 


^^^^ 


This  catalog,  and  the  data  that  is  stored  off 
site,  HBUJt  contain  all  of  your  "must"  m 
systems  and  as  many  of  your  *^nrn  nnitiir^ 
systems  as  you  can  reasonably  keep  curren 
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Which  leads  us  to  the  final  point  of  this 
section  -  making  sure  that,  as  you  bacl<  up 
your  system  for  normal  securit)^  purposes, 
you  transfer  updated  master  files, 
necessary  transaction  files  and,  if 
pertinent,  new  documentation  files  (or  hard 
copy)  to  the. vault.  This  ongoing  effort 
5l«*«kt  be  done  at  least  monthly  and  s>Ut><i> 

probably^on  a  weekly  basis  in  order  to  * 
preclude  a  need  to  have  to  manually 
recreate  as  much  as  30  days  worth  of 

transaction  data,  "^r/^^^ 'i>/S/f«?E;g_  >o£5' u^'Li-  ^vt-  ^^''-L.  /'if/o/€T/UJ>'y 

Key  Personnel 


When,  or  if,  a  disaster  occurs,  the  key 
word  (ROi-informatioF»^#Hs^4fl^€^o 
remember  is  disaster.  You  will  potentially 
have  to  process  information  in  a  scramble 


mode/^a  worst  case  situation,  you  not  only 

well. ^ This  means  that  other  staff  members 
will  have  to  try  to  process  as  much  of  the 
information  they  can  with  limited 
supervision  and  decreased  processing 
capabilities. 

By  maintaining  a  list  of  all  key 
personnel  at  at  least  three  locations,  the 
vault,  on-site,  and  at  the  house  of  one  (or 
more)  staff  members,  you  will  have  an 
ability  to  process.  For  each  person 
identified,  there  should  be  at  least  one, 
preferably  two,  back-up  individuals 
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indicated  who  can  support  your  processing 

needs.  Operations,  applications 

programming  and  systems  software  are  ihe 

three  disciplines  that  must  be  protected 

with  customer  support,  documentation,  data 

entry,  etc.  important  but  prfabffhly  ias^^e^ 

than  these  first  three. 

If  you  are  a  one-shift,  one  level  of 

staffing  shop,  you  need  to  consider  locating 

and  arranging  for  a  third  party  to  support 

your  system  » the  need  arise*.  -Sr  this 

"'^•'•^Jir   •  ceM<o>, tit- 
case,  the  key  contact^4*r  this  outside 

organization  is  kept  at  the  locations 

mentioned  above. 


ctmrw  ^^f^'^^ 


-t^r-m^g  A^-TuuL!^  Til 


Processing  Facilities 


You  now  have  the  people,  the 
programs,  reasonably  current  updated 
rec<irds  and  documentation.  All  you  need  is  UoO 
a^place  to  run^  Remembering  still  that 
disaster  is  the  key  word,  you  will  have: 

with  a  sister  firm  in  another 
locale  to  support  your  needs  for  some 
period  of  time.  (Remember  that  these 
kinds  of  arrangements  are^'^^'P^.^^ 

b)  M^M^i>  with  a  service  organization  in 

another  location  to  support  you  until 
your  installation  has  recovered. 

c)  Au0K^  for  an  space-only  location  into 

which  a  new  hardware  configuration 

can  be  delivered  as  soon  as  your  vendor 

can  JSSi^/'?*'  ^'TX  77e  tJcezth  j^'^^'^T 
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In  addition,  you,  as  part  of  this 
requirement,  will  have  a  guarantee  from 
your  vendor  describing  how  long  it  will  take 
to  get  that  new  system  to  your  space«only 
backup  site  or  to  your  new  or  renovated 
location.  ^  ^ 

r^w  Ihdl  wusn'rTrtt-thot~dif«Gt4tr^y 
/overing  these  three  areas,  you  give 
yourself  primary  protection  against  a 
disaster  putting  your  organization  in  <*wm%, 
or  worsp,  out  of  business.  There  are  a  lot 

A. 

of  other  items  that  need  to  be  looked  at  In 
the  proper  completion  of  a  disaster  (^Luos/tA-'^ 

transportation,  data  entry,  communications, 
supplies,  etc.  But,  by  handling  the  basic 
three^you  should  be  able  to  keep  yourself 
going  regardless  of  the  magnitude  of  the 

disaster.  ^^^^^^  ^     pnc^oCf^  F^a^j^ 

And,- you  have  begun  a/QTsoster 
recovery  plan^that  you  should^complete  as 
soon  as  you  can  find  the  time  or  get  out 

from  under  those  other  P'''°'''*';jp^^.^^,^^y^^Q) 

This  ^;>^\^,.,_^xecutive  Bulletin  Is 
intended  to  remind  you  that  not  only  doesn't 
it  not  pay  to  fool  with  mother  nature,  it 
doesn't  pay  to  ignore  her  either. 

t/U-^'^'A^  ^/^-i^ityS- 


Ha^P*-^  ,  ^UO^^  C#>vT^^_  5_4MMEB-2)  TE  5/r/B5  .       .  ^/  ^39^d 


0^     ^^oJj^     Oi<:?Aj^tu^  .^.JLJL^Ti^JL^ 


t.. 


c^uM  UJJ   

C^'-Toi.'-rtU./'iiAjfl^^  

73  .  
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An  Unusually  Noteworthy 
Introduction  of  a 
Xenolith* 

Eight  years  ago,  INPUT  predicted  a 
battle  between  two  giants  as  computer  and 
connmunications  technologies  merged  into 
integrated  networks.  Since  then,  IBM 
revenue  has  grown  from  $16  billion  to  $40 
billion,  and  the  Bell  System  has  been  broken 
up.  From  a  hardware  point  of  view,  AT&T 
Technologies  Inc.'s  announcement  of  its  3B 
line  of  32-bit  processors  is  strictly  David 
versus  Goliath,  but  David's  sling  is  armed 
with  a  xenolith  aimed  directly  at  Goliath's 
software  monolith.  The  UNIX  shot  was 
telegraphed  from  way  back,  and  Goliath 
looks  bored  by  these  developments;  but  we 
have  all  been  waiting  for  this  match,  so 
let's  take  a  look  at  it. 

1.  The  Target  is  Right! 

2.  SNA  Xenophobia 


The  Target  is  Right! 

INPUT  predicted  the  IBM-AT&T  battle  in 
the  Economics  of  Computer/Communica-  i 
tions  Networks  and  Their  Future  Impact, 
March  1976.  That  report  also  described 
hierarchical  networks  consisting  of  very 
large  mainframes  ($4  million  price  range), 
minicomputers  (less  than  $200,000),  and 
intelligent  terminals  (less  than  $20,000)  and  | 
defined  their  "proper  functions"  as  follows:  | 

-  Mainframes  -  heavy  computation, 
transaction  processing  against  large 
data  bases,  and  RJE  replacement  of 
standalone  batch  systems.  | 

-  Minicomputers  -  network  control, 
scientific  timesharing,  program 
development  and  maintenance,  and 
simple  transaction  processing. 

-  Intelligent  Terminals  -  collection, 
editing,  and  display  of  data;  control  of 
lower  level  terminals  (input-output 
devices). 


3.       VM/CMS/MVS/XA/UNIX  - 
Excalibur? 


*  Xenolith  -  A  fragment  of  rock  included  in 
another  rock 


I 


In  a  brief  analysis  of  IBM's  then  recently 
announced  Systems  Network  Architecture 
(SNA),  INPUT  stated:  ".  .  .there  is  little 
indication  that  IBM  either  understands  or 
has  any  intention  of  implementing  networks 
incorporating  multifunction  Level  lis  (mini- 
computers). .  ."  In  the  last  eight  years, 
INPUT  has  seen  no  reason  to  revise  this 
opinion.  IBM  has  used  SNA  as  a  means  of 
excluding  minis  (including  their  own  Series 
I)  from  their  "proper"  (and  cost-effective) 
place  in  the  processing  hierarchy.  How- 
ever, the  advantages  of  minicomputers  for 
the  communications-oriented,  interactive 
functions  assigned  to  them  have  become 
apparent,  and  growth  in  the  use  of  mini- 
computers has  substantially  impacted 
general  mainframe  growth. 

All  of  IBM's  alternatives  to  the  use  of 
minicomputers  (from  large  host  processing 
down  through  the  relatively  recent  an- 
nouncements of  the  4361  and  XT/370) 
suffer  from  the  same  problem  -  they  must 
compete,  burdened  by  software  that  was 
not  specifically  designed  for  the  communi- 
cations-oriented, interactive  environment 
in  which  minicomputers  thrive. 

David  seems  to  have  adopted  a  rather 
clever  strategy.  During  the  first  round  he 
has  targeted  a  hardware  area  where  Goliath 
has  seen  fit  to  avoid  one-on-one  combat.  In 
fact,  David  may  knock  over  a  few  of  Goli- 
ath's   smaller    minicomputer  tormentors 


while  in  the  process  of  directing  his  UNIX 
xenolith  at  Goliath's  softest  spot  -  soft- 
ware. However,  David  may  find  even 
Goliath's  soft  spot  difficult  to  penetrate. 


SNA  XenoF>hobia 

One  analyst  reacted  to  the  3B  series 
announcement  with  the  statement:  "High 
tech,  high  price."  And,  in  fact,  the  prices 
of  the  high-end  3B205,  A  &  D  ($230,000  to 
$340,000)  seem  aimed  more  at  the  IBM  436 1 
and  4381  mainframes  than  they  are  at  the 
Data  General  and  DEC  lines  of  superminis 
(which  still  fall  below  INPUT'S  $200,000 
definition  for  minicomputers).  However,  it 
should  not  necessarily  be  assumed  that 
David  has  missed  the  target  completely. 

-  The  3B  series  is  aimed  at  the  office 
and  local  area  networks.  Two  Ether- 
net-compatible interfaces  are  pro- 
vided, but  3B  Net  is  reported  to  have 
five  times  the  throughput  of  current 
Ethernet-type  LANs  with  significantly 
less  burden  on  the  attached  proces- 
sors. 

-  The  processors  are  stated  to  be  twice 
as  reliable  as  other  commercially 
available  computers  (10  minutes 
downtime  per  year)  and  operate 
within  a  temperature  range  of  32°F  to 
I220F. 


-  In  fact,  the  3B20  (as  specified)  is 
more  like  the  #5  ESS  switching 
systems  than  it  is  a  conventional 
minicomputer.  As  such,  its  life 
expectancy  is  probably  projected  to 
be  longer  than  commercially  available 
minicomputers  and  most  certainly 
longer  than  IBM  mainframes  where 
planned  obsolescence  is  the  order  of 
the  day. 


The  extended  life,  plus  performance 
under  UNIX,  should  result  in  a  rela- 
tively cheap  cost  when  measured  on 
the  basis  of  cost  per  terminal  over  the 
life  cycle.  Office  systems  are  com- 
munications systems,  and  it  should  be 
hoped  that  their  reliability,  perform- 
ance, and  effective  life  will  more 
closely  parallel  those  of  communica- 
tions networks  rather  than  data 
processing  systems. 


The  385/ 1 00  and  200  are  based  on  a  32- 
bit  microprocessor  developed  by  AT&T's 
Technology  Systems  Group.  They  are 
classified  as  "mid-range  superminis,"  are 
purported  to  be  optimized  for  UNIX,  sup- 
port 30  and  60  users  respectively,  and  sell 
for  between  $57,000  and  $73,000.  The 
3B2/300  (based  on  the  same  microprocessor) 
is  a  desktop  unit  that  sells  for  $9,500, 
supports  up  to  18  users,  and  later  this  year 


will  provide  a  UNIX  host  for  personal 
computers  (IBM  PC  and  compatibles)  in- 
cluding an  anticipated  '  3BX  personal 
computer. 


The  3B  line  is  a  well-planned,  high- 
quality,  hardware/software  system  from  the 
only  vendor  with  a  chance  to  match  Goli- 
ath's reputation  -  but  it  all  depends  on 
UNIX.  An  AT&T  spokesperson  has  stated 
that  the  announcement  of  UNIX  System  V 
has  moved  it.  "beyond  academics  and  tech- 
nical gurus."  Perhaps  this  is  true,  but  when 
one  of  the  10,000  marketing  representatives 
AT&T  plans  to  employ  by  the  end  of  the 
year  (a  major  challenge  in  its  own  right) 
calls  on  a  typical  IBM,  SNA-oriented  IS 
department,  the  rep  is  likely  to  find  a 
xenophobe  who  views  both  the  rep  and  the 
xenolith  as  something  from  outer  space. 


VM/CMS/MVS/XA/UNIX  -  Excalibur? 

However,  David's  first  shot  may  hit  the 
target  among  some  of  Goliath's  most  valued 
customers  -  those  large  enough  and  ad- 
vanced enough  to  push  the  state-of-the-art 
in  networks.  In  that  case,  Goliath  may  be 
temporarily  stunned  and  the  fight  may 
proceed  to  round  two.  Then  David  will  be 
armed  with  a  UNIX  sword  rather  than  a 
mere  sling  and  stone.  Even  though  Goliath 
may  be  reduced  from  giant  to  king  size,  you 


can  be  sure  he  will  have  the  strength  to 
wrest  the  sword  from  David  and  ennbed  it 
firmly  in  the  solid,  unfathomable  IBM 
software  monolith. 

UNIX  will  become  just  a  part  (and  from 
IBM's  point  of  view,  a  minor  part)  of  the 
greater  VM/CMS/MVS/XA  whole.  IBM's 
agreement  with  Computervision  for  the 
development  of  a  4300-based 
CAE/CAD/CAM  system  under  VM/CMS  and 
the  SQL/DS  relational  DBMS,  using  UNIX 
only  at  the  intelligent  workstation  level, 
will  give  some  idea  of  how  deeply  IBM 
would  prefer  to  push  the  sword  into  the 
stone.  However,  UNIX  could  be  run  as  "just 
another  operating  system"  under  VM  at  any 
level.  Thus  will  the  challenge  be  laid  down 
during  round  two,  and  it  will  remain  to  be 
seen  whether  David  can  turn  into  Arthur 
and  wrest  Excalibur  from  the  stone  in  order 
to  fight  another  round. 


In  the  meantime,  the  combined  hard- 
ware/software implications  of  the  an- 
nouncement must  be  analyzed  because  of 
their  potential  impact  on  network  architec- 
ture, performance,  and  productivity.  The 
INPUT  research  program  for  this  year 
provides  in-depth  coverage  of  all  of  these 
areas. 


This  INPUT  Executive  Bulletin  is 
published  as  part  of  the  Corporate  Systems 
Planning  Program  of  the  Information 
Systems  Program.  For  more  information  on 
this  bulletin,  or  on  this  or  any  other  INPUT 
program,  contact  INPUT  at  1943  Landings 
Drive,  Mountain  View,  California  94043, 
(415) 960-3990. 
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An  Unusually  Noteworthy 
Introduction  of  a 
Xenolith* 

Eight  years  ago,  INPUT  predicted  a 
battle  between  two  giants  as  computer  and 
communications  technologies  merged  into 
integrated  networks.  Since  then,  IBM 
revenue  has  grown  from  $16  billion  to  $40 
billion,  and  the  Bell  System  has  been  broken 
up.  From  a  hardware  point-JofXiew,  AT&T 
Technologies/lnc.'s  announcement  of  its  3B 
line  of  32-bit  processors  is  strictly  David 
versus  Goliath,  but  David's  sling  is  armed 
with  a^xenolith  aimed  directly  at  Goliath's 
software  monolith.  The  UNIX  shot  was 
telegraphed  from  way  back,  and  Goliath 
looks  bored  by  these  developments^ but  we 
have  all  been  waiting  for  this  match,  so 
let's  take  a  look  at  it. 

1.  The  Target  is  Right! 

2.  SNA  Xenophobia 


The  Target  is  Right! 

INPUT  predicted  the  IBM-AT&T  battle  in 
the  Economics  of  Computer/Communica- 
tions Networks  and  Their  Future  Impact, 
March  1976.  That  report  also  described 
hierarchical  networks  consisting  of  very 
large  mainframes  ($4  million  price  range), 
minicomputers  (less  than  $200,000),  and 
intelligent  terminals  (less  than  $20,000)  and 
defined  their  "proper  functions"  as  follows: 

-  Mainframes  -  heavy  computation, 
transaction  processing  against  large 
data  bases,  and  RJE  replacement  of 
standalone  batch  systems. 

-  Minicomputers  -  network  control, 
scientific  timesharing,  program 
development  and  maintenance,  and 
simple  transaction  processing. 

-  Intelligent  Terminals  -  collection, 
editing,  and  display  of  data;  control  of 
lower  level  terminals  (input-output 
devices). 


3. 


VM/CMS/MVS/XA/UNIX  - 
Excalibur? 


*  Xenolith  -  A  fragment  of  rock  included  in 
another  rock 


1 


J 


In  a  brief  analysis  of  IBM's  then  recently 
announced  Systems  Network  Architecture 
(SNA),  INPUT  stated:  '''j|there  is  little 
indication  that  IBM  either  understands  or 
has  any  intention  of  implementing  networks 
incorporating  multifunction  Level  lis  (mini- 
computers)^^" In  the  last  eight  years, 
INPUT  has  seen  no  reason  to  revise  this 
opinion.  IBM  has  used  SNA  as  a  means  of 
excluding  minis  (including  their  own  Series 
I)  from  their  "proper"  (and  cost-effective) 
place  in  the  processing  hierarchy.  How- 
ever, the  advantages  of  minicomputers  for 
the  communications-oriented,  interactive 
functions  assigned  to  them  have  become 
apparent,  and  growth  In  the  use  of  mini- 
computers has  substantially  impacted 
general  mainframe  growth. 

All  of  IBM's  alternatives  to  the  use  of 
minicomputers  (from  large  host  processing 
down  through  the  relatively  recent  an- 
nouncements of  the  k36\  and  XT/370) 
suffer  from  the  same  problem  -  they  must 
compet^burdened  by  software  that  was  not 
specifically  designed  for  the  communica- 
tions-oriented, interactive  environment  in 
which  minicomputers  thrive. 

David  seems  to  have  adopted  a  rather 
clever  strategy.  During  the  first  round  he 
has  targeted  a  hardware  area  where  Goliath 
has  seen  fit  to  avoid  one-on-one  combat.  In 
fact,  David  may  knock  over  c  few  of  Goli- 
ath's   smaller    minicomputer  tormentors 


while  in  the  process  of  directing  his  UNIX 
xenolith  at  Goliath's  softest  spot  -  soft- 
ware. However,  David  may  find  even 
Goliath's  soft  spot  difficult  to  penetrate. 


SNA  Xenophobia 

One  analyst  reacted  to  the  3B  series 
announcement  with  the  statement:  "High 
;  tech,  high  price."  And,  in  fact,  the  prices 
of  the  high-end  3B205,  A  &  D  ($230,000  to 
$340,000)  seem  aimed  more  at  the  IBM  436 1 
and  4381  mainframes  than  they  are  at  the 
Data  General  and  DEC  lines  of  superminis 
(which  still  fall  below  INPUT'S  $200,000 
definition  for  minicomputers).  However,  It 
should  not  necessarily  be  assumed  that 
David  has  missed  the  target  completely. 

-  The  3B  series  is  aimed  at  the  office 
and  local  area  networks.  Two  Ether- 
net-compatible interfaces  are  pro- 
vided, but  3B  Net  is  reported  to  have 
five  times  the  throughput  of  current 
Ethernet-type  LANs  with  significantly 
less  burden  on  the  attached  proces- 
sors. 

-  The  processors  are  stated  to  be  twice 
as  reliable  as  other  commercially 
available  computers  (10  minutes 
downtime  per  year)  and  operate 
within  a  temperature  range  of  32°F  to 
I220F. 


-  In  fact,  the  3B20  (as  specified)  is 
more  like  the  #5  ESS  switching 
systems  than  it  is  a  conventional 
minicomputer.  As  such,  its  life 
expectancy  is  probably  projected  to 
be  longer  than  commercially  available 
minicomputers  and  most  certainly 
longer  than  IBM  mainframes  where 
planned  obsolescence  is  the  order  of 
the  day. 


-  The  extended  life,  plus  performance 
under  UNIX,  should  result  in  a  rela- 
tively cheap  cost  when  measured  on 
the  basis  of  cost  per  terminal  over  the 
life  cycle.  Office  systems  are  com- 
munications systems,  and  it  should  be 
hoped  that  their  reliability,  perform- 
ance, and  effective  life  will  more 
closely  parallel  those  of  communica- 
tions networks  rather  than  data 
processing  systems. 


The  385/ 1 00  and  200  are  based  on  a  32- 
bit  microprocessor  developed  by  AT&T's 
Technology  Systems  Group.  They  are 
classified  as  "mid-range  superminis,"  are 
purported  to  be  optimized  for  UNIX,  sup- 
port 30  and  60  users  respectively,  and  sell 
for  between  $57,000  and  $73,000.  The 
3B2/300  (based  on  the  same  microprocessor) 
is  a  desktop  unit  that  sells  for  $9,500, 
supports  up  to  18  users,  and  later  this  year 


will  provide  a  UNIX  host  for  personal 
computers  (IBM  PC  and  compatibles)  in- 
cluding an  anticipated  3BX  personal 
computer. 


The  3B  line  is  a  well-planned,  high- 
quality,  hardware/software  system  from  the 
only  vendor  with  a  chance  to  match  Goli- 
ath's reputation  -  but  it  all  depends  on 
UNIX.  An  AT&T  spokesfP^has  stated  that 
the  announcement  of  Unix.  System  V  has 
moved  it  "beyond  academics  and  technical 
gurus."  Perhap^  but  when  one  of  the 
10,000  marketing  representatives  AT&T 
plans  to  employ  by  the  end  of  the  year  (a 
major  challenge  in  its  own  right)  calls  on  a 
typical  IBM,  SNA-oriented  IS  department, 
the  rep  is  likely  to  find  ap  xenophobe  who 
views  both  4wTr  and  (hty^enolith  as  some- 
thing from  outer  space. 


yM/CI^S/MWS/XA/UN\X  -  Excalibur? 

However,  David's  first  shot  may  hit  the 
target  among  some  of  Goliath's  most  valued 
customers  -  those  large  enough  and  ad- 
vanced enough  to  push  the  state-of-the-art 
in  networks.  In  that  case,  Goliath  may  be 
temporarily  stunned  and  the  fight  may 
proceed  to  round  two.  Then  David  will  be 
armed  with  a  UNIX  sword  rather  than  a 
mere  sling  and  stone.  Even  though  Goliath 
may  be  reduced  from  giant  to  king  size,  you 


can  be  sure  he  will  have  the  strength  to 
wrest  the  sword  from  David  and  embed  it 
firmly  in  the  solid,  unfathomable  IBM 
software  monolith. 

UNIX  will  become  just  a  parti  of  the 
greater  VM/CMS/MVS/XA  whol^/1^ 
hopoRj||';^rom  IB/VVs  point^f^viev^ minor 
pari)Jy^Bt\A's  agreement  with  Computer- 
vision  for  the  development  of  a  4300-based 
CAE/CAD/CAM  system  under  VM/CMS  and 
the  SQL/DS  relational  DBMS,  using  UNIX 
only  at  the  intelligent  workstation  level, 
will  give  some  idea  of  how  deeply  IBM 
would  prefer  to  push  the  sword  into  the 
stone.  However,  UNIX  could  be  run  as  "just 
another  operating  system"  under  VM  at  any 
level.  Thus  will  the  challenge  be  laid  down 
during  round  two,  and  it  will  remain  to  be 
seen  whether  David  can  turn  into  Arthur 
and  wrest  Excalibur  from  the  stone  in  order 
to  fight  another  round. 


In  the  mean  time,  the  combined  hard- 
ware/software  implications  of  the  an- 
nouncement must  be  analyzed  because  of 
their  potential  impact  on  network  architec- 
ture, performance,  and  productivity.  The 
INPUT  research  program  for  this  year 
provides  in-depth  coverage  of  all  of  these 
areas. 
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Systems  Program.  For  more  information  on 
this  bulletin,  or  on  this  or  any  other  INPUT 
program,  contact  INPUT  at  1943  Landings 
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AN  UNUSUALLY  NOTEWORTHY 
INTRODUCTION  OF  A 
)<ENOLITH  ^ 

Eight  years  ago,  INPUT  predicted  a 
battle  between  two  giants  as  connputer  and 
communications  technologies  merged  into 
integrated  networks.  Since  then,  IBM 
revenue  has  grown  from  $16  billion  to  $40 
billion,  and  the  Bell  System  has  been  broken 
up.  From  a  hardware  point-of-view,  the-J^ 
AT&T  Technologies,  Inc.'s  announcement  of 
its  3B  line  of  32-bit  processors  is  strictly 
David  versus  Goliath,  but  David's  sling  is 
armed  with  an  xenolit^  aimed  directly  at 
Goliath's  software  monolit^.  The  UNIX 
shot  was  telegraphed  frfrn  way  back,  and 
Goliath  looks  pmU^u^^  but  we  have 

all  been  waiting  for  this  match,  so  let's  take 
a  look  at  it. 


1.  The  Target  is  Right! 

2.  SNA  Xenophobia 

3.  VM/CMS/MVS/XA/UNIX  - 
Excalibur? 
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The  Target  is  Right! 


INPUT  predicted  the  IBM-AT&T 
battle  in  the  Economics  of 
Connputer/Communications  Networks  and 
Their  Future  Impact,  March  1976.  That 
report  also  described  hierarchical  networks 
consisting  of  very  large  mainframes  ($4 
million  price  range),  minicomputers  (less 
than  $200,000),  and  intelligent  terminals 
(less  than  $20,000)  and  defined  their  "proper 
functions"  as  follows: 

Mainframes  -  heavy 
computation,  transaction 
processing  against  large  data 
bases,  and  RJE  replacement  of 
standalone  batch  systems. 

Minicomputers  -  network 
control,  scientific  timesharing, 
program  development  and 
maintenance,  and  simple 
transaction  processing. 

Intelligent  Terminals  - 
collection,  editing,  and  display 
of  data;  sn^control  of  lower 
level  terminals  (input-output 
devices). 

In  a  brief  analysis  of  IBM's  then 
recently  announced  Systems  Network 
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Architecture  (SNA),  INPUT  stated: 
"...there  is  little  indication  that  IBM  either 
understands  or  has  any  intention  of 
implementing  networks  incorporating 
multifunction  Level  lis  (minicomputers) 
..."  In  the  last  eight  years,  INPUT  has  seen 
no  reason  to  revise  this  opinion.  IBM  has 
used  SNA  as  a  means  of  excluding  minis 
(including  their  own  Series  I)  from  their 
"proper"  (and  cost^ffective)  place  in  the 
processing  hierarchy.  However,  the 
advantages  of  minicomputes  for  the 
communications-oriented,  interactive 


functions  assigned  to  them  have  become 
apparent,  and  growth  in  the  use  of 
minicomputers  has  substantially  impacted 
general  mainframe  growth. 

All  of  IBM's  alternatives  to  the  use  of 
minicomputers  (from  large  host  processing 
down  through  the  relatively  recent 
announcements  of  the  4361  and  XT/370) 
suffer  from  the  same  problem  -  they  must 
compete  burdened  by  software  w^f^  was 
not  specifically  designed  for  the 
communications-oriented,  interactive 
environment  in  which  minicomputers  thrive. 

David  seems  to  have  adopted  a  rather 
clever  strategy.  During  the  first  round  he 
has  targeted  a  hardware  area  where  Goliath 
has  seen  fit  to  avoid  one-on-one  combat.  In 
fact,  David  may-punch  out  a  few  of 


A 
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Goliath's  smaller  minicomputer  tormentors 
while. in  the  process  of  directing  his  UNIX 
xepouty  at  Goliath's  imjsj  jen^  spot  - 
software.  However,  David  may  find  even 
Goliath's  soft  spot  difficult  to  penetrate. 

SNA  Xenophobia 

One  analyst  reacted  to  the  3B  series 
announcement  with  the  statement:  "High 
tech,  high  price."  And,  in  fact,  the  prices 
of  the  high^end  3B205,  A  &  D  ($230,000  to 
$340,000)  seem  aimed  more  at  the  IBM  436 1 
and  4381  mainframes  than  they  are  at  the 
Data  General  and  DEC  lines  of  superminis 
(which  still  fall  below  INPUT'S  $200,000 
definition  for  minicomputers).  However,  it 
should  not  necessarily  be  assumed  that 
David  has  missed  the  target  completely. 

The  3B  series  is  aimed  at  the 
office  and  local  area 
networks.  Two  Ethernet- 
compatible  interfaces  are 
provided,  but  3B  Net  is 
reported  to  have  five  times  the 
throughput  of  current 
Ethernet-type  LANs  with 
significantly  less  burden  on  the 
attached  processors. 

The  processors  are  stated  to  be 
twice  as  reliable  as  other 
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commercially  available 
computers  (10  minutes 
downtime  per  year)  and 
operate  within  a  temperature 
range  of  320F  to  I22°F. 

In  fact,  the  3B20^s  specified^is 

more  like  the  #5  ESS  switching 

systems  than  it  is  a 

conventional  minicomputer. 
9- 

As  such,  it's  life  expectancy  is 
probably  projected  to  be  longer 
than  commercially  available 
minicomputers  and  most 
certainly  longer  than  IBM 
mainframes  where  planned 
obsolescence  is  the  order  of 
the  day. 

The  extended  life,  plus 
performance  under  UNIX, 
should  grve- relatively  cheap 
cost  when  measured  on  the 
basis  of  cost  per  terminal  over 
the  life  cycle.  Office  systems 
are  communications  systems, 
and  it  should  be  hoped  that 
their  reliability,  performance, 
and  effective  life  will  more 
closely  parallel  those  of 
communications  networks 
rather  than  data  processing 
systems. 
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The  385/ 1 00  and  200  are  based  on  a 
32-bit  microprocessor  developed  by  AT&T's 
Technology  Systems  Group.  They  are 
classified  as  "mid-range  superminis,"  are 
purported  to  be  optimized  for  UNIX, 
supp|^  30  and  60  users  respectively,  and 
sell  for  between  $57,000  and  $73,000.  The 
3B2/300  (based  on^^i^  same  microprocessor) 
is  a  desktop  unit  wWeh  sells  for  $9,500, 
supports  up  to  18  users,  and  later  this  year 
will  provide  a  UNIX  host  for  personal 
computers  (IBM  PC  and  compatibles)^ 
including  an  anticipated  3BX  personal 
computer. 

The  3B  line  is  a  well-planned,  high-j; 


quality,  hardare/software  system  from  the 

only  vendor  with  a  chance  to  match 
J, 

Goliath's  reputatior^but  it  all  depends  on 
UNIX.  An  AT&T  spokesman  has  stated  that 
the  announcement  of  Unix  System  V  has 
moved  it  "beyond  academics  and  technical 
gurus."  Perhaps,  but  when  one  of  the 
10,000  marketing  representatives  AT&T 
plans  to  employ  by  the  end  of  the  year  (a 
major  challenge  in  its  own  right)  calls  on  a 
typical  IBM,  SNA-oriented  IS  department. 


he  is  likely  to  find  an  xenophobe  who  views 
both  him  and  his  xenolith  as  something  from 
outer  space. 


A 
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VM/CMS/MVS/XA/UNIX  -  Excolibur? 

However,  David's  first  shot  may  hit 
the  target  among  some  of  Goliath's  most 
valued  customers  -  those  large  enough  and 
advanced  enough  to  push  the  state-of-the- 
art  in  networks.  In  that  case,  Goliath  may 
be  temporarily  stunned  and  the  fight  may 
proceed  to  round  two.  Then  David  will  be 
armed  with  a  UNIX  sword  rather  than  a  J 
mere  sling  and  stone.  Even  though  Goliath 


may  be  reduced  from  giant  to  king  size^you 
can  be  sure  he  will  have  the  strength  to 
wrest  the  sword  from  David  and  inrohm^t 
firmly  in  the  solid,  unfathomableTsM 
software  monolith. 


UNIX  will  become  just  a  part  of  the 
greater  VM/CMS/MVS/XA  whole  (and 
hopefully  from  IBM's  point-of-view  a  minor 
part).  IBM's  agreement  with 
Computervision  for  the  development  of  a 
4300-based  CAE/CAD/CAM  system  under 
VM/CMS  and  the  SQL/DS  relational  DBMS, 
using  UNIX  only  at  the  intelligent 
workstation  level^ill  give  some  idea  of 
how  deeply  IBM  would  prefer  to  push  the 
sword  into  the  reck.  However,  UNIX  could 
be  run  as  "just  another  operating  system" 
under  VM  at  an(^  level.  Thus  will  the 
challenge  be  laid  down  during  round  two, 
and  it  will  remain  to  be  seen  whether  David 
can  turn  into  Arthur  and  wrest  Excolibur 
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from  therock  in  order  to  fight  another 
round. 


in  the  mean  time,  the  combined 

harctare/software  implications  of  the 
/\ 

qpnouncement  must  be  analyzed  because  of 
i+s-potential  impact  on  network 
architecture,  performance,  and 
productivity.  The  INPUT  research  program 
for  this  year  provides  in-depth  coverage  of 
all  of  these  areas. 
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